Enterprises, such as business enterprises, governmental enterprises, and private enterprises, often employ a number of systems (whether hardware, software, or combinations thereof) for providing functionality useful to the operation of the enterprise. For example, an enterprise may employ a complex computer network and communication system in order to facilitate information communication, processing, storage, analysis, modeling, etcetera. The aforementioned computer network may provide desired functionality through the use of various software systems, such as may comprise one or more software applications (referred to herein as applications) addressing particular aspects of the enterprise operations.
As but one example, for an enterprise providing healthcare services such applications may include a case management application, a credentialing application, a financial application, a membership management application, a commissions application, a customer service application, a provider network management application, a claims processing application, etcetera. Efficient operation of the enterprise may suggest that information from one or more such application should be exchanged (advantageously in real-time) with another one or more such application. However, each such application may utilize proprietary data formats, incompatible data inputs/outputs, or otherwise present barriers to their directly interfacing for desired information exchange making these applications not only disparate with respect to function but also disparate with respect to interfacing.
Further compounding the difficulties associated with the ability to provide information exchange between such an enterprise's applications, an enterprise may utilize more than one of any or all of the foregoing applications, wherein one or more applications providing a same or similar function may also be disparate. For example, a healthcare services enterprise may acquire or merge with another healthcare services enterprise, each having a number of systems, including different ones of the foregoing applications, for providing functionality useful to the operation of the enterprise. Thus, for example, an insurer (an example of a healthcare services enterprise) may comprise a plurality of disparate claims processing applications. Migration to one platform is likely to be costly and time consuming, thereby resulting in various legacy applications being used in parallel with other applications providing the same or similar functionality.
Approaches to providing integration between enterprise applications have included enterprise application integration (EAI) efforts which typically result in an EAI application uniquely tailored to a situation to provide interfacing between a plurality of specific enterprise applications. For example, an EAI application will typically be adapted to interface with particular enterprise applications and will provide a data path between particular ones of these applications (e.g., point-to-point interfacing). EAI applications have provided enterprise application interfacing in batch processing modes or in real-time processing modes, but heretofore have not offered a combination of batch processing and real-time processing.
EAI applications are generally a centralized application requiring considerable resources and manpower to operate and maintain. Although the software applications themselves often provide stable and reliable operation, EAI applications tend to be less stable and present reliability issues with respect to the application interfaces provided thereby failing or degrading. There has heretofore been no ability to monitor the performance of interfaces provided by EAI applications or to validate that they are working, without an operator actually monitoring the operation of the interfaces.
Moreover, EAI applications typically adopt a “stove pipe” configuration wherein they implement proprietary data interchange architecture and are adapted for use with only specific applications. If an enterprise, using a typical EAI application to provide interfacing between applications, changes, adds, or removes an application, the interface provided will be broken. Therefore, the EAI application will require corresponding modification, such as to add a new interface or modify an existing interface in order to support changes with respect to the enterprise applications. Such EAI application modifications are typically costly and time consuming, resulting in a reluctance, or an inability, to implement enterprise application changes.
The “stove pipe” configuration of EAI applications presents a “hard wired” interface between software applications in that data, or particular data, provided by a first software application is directed to a second software application in accordance with hard coding of an interface provided by the EAI application. If it is later desired to route data from the first software application to a third software application, the EAI application must be modified to create a new interface or modify an existing interface.
Moreover, stove pipe configurations of EAI applications can only provide limited routing of data based upon transaction information. For example, although an EAI application may be hard coded to make a simple determination as to a routing branch determination based upon limited information, such routing is based upon proprietary technology and has not provided robust and flexible intelligent routing based upon a large variety of transaction information. When it is determined that alternative routing of data between applications is desired, a highly technical individual must typically be employed to make code changes to the EAI application.
Accordingly, a need exists in the art for a software application interface which is more easily supported. A further need exists in the art for a software application interface which provides flexibility. A still further need exists in the art for a software application interface which supports intelligent routing based upon a variety of transaction information.